One problem of conventional network devices is that flexible load control, such as load distribution and load concentration, cannot be achieved by an external control. This makes it difficult to monitor and improve the system behavior in a large-scale network, causing a problem that a modification in the system design and/or configuration requires a large cost.
One proposed approach for solving this problem is separation of the packet transfer function and the route control function which are both conventionally implemented by a network device. For example, in a system in which the packet transfer function is assigned to network devices and the control function is assigned to a controller provided separately from the network devices, the controller can perform centralized management of packet transfer, which allows establishing a network with high flexibility.
(CD-Separated Network)
One proposed function-separated network is a CD-separated network (where C stands for control plane and d stands for data plane), in which a controller operating on the control plane controls node devices operating on the data plane.
One example of the CD-separated network is an OpenFlow network which is based on the OpenFlow technique, in which the route control in the network is achieved by controlling switches by a controller. Details of the OpenFlow technique are disclosed in non-patent documents 1 and 2. Note that the OpenFlow network should be construed as one example.
(OpenFlow Network)
In an OpenFlow network, a controller, such as an OpenFlow controller (OFC), controls the behavior of node devices, such as OpenFlow switches (OFSs), by processing route control information (or a flow table) which describes the route control of the node devices.
Controllers and node devices are connected via control channels (communication channels for control) called “secure channels”, which are communication paths protected by using dedicated lines or an SSL (Secure Socket Layer) technique. Controllers and node devices exchange OpenFlow messages defined in the OpenFlow protocol via control channels.
In the OpenFlow network, each node device is provided in the OpenFlow network and controlled by the controller; each node device may be an edge switch or a core switch. A series of packet transfers from the receipt of a packet at an ingress edge switch to the transmission at an egress edge switch in the OpenFlow network is referred to as “flow”. In the OpenFlow network, communications are each regarded as an end-to-end flow, and the route control, the trouble recovery, and the load distribution and optimization are carried out in units of flows.
It should be noted that the frame should be regard as an alternative of the packet. The difference between the packet and the frame only lies in the difference in the protocol data unit (PDU). The packet is the PDU of the TCP/IP (transmission control protocol/internet protocol). On the other hand, the frame is the PDU of the “Ethernet” (registered trademark).
The route control information (or the flow table) includes a set of: identifying conditions (identifying rules) to identify packets to be treated as a flow; statistical information that indicates the number of times in which packets comply or match with the identifying conditions (or the identifying rules); and processing rules (or flow entries) which define a group of contents of processing (or actions) to be performed on packets.
The identifying conditions (or the identifying rules) of each processing rule (or each flow entry) are defined by various combinations of any or all of data of respective protocol hierarchies included in the header region (or the header field) of the packet, and distinguishable one another by using these data. One example of data of the respective protocol hierarchies may include the destination address, the source address, the destination port, the source port. Note that the above-described addresses may be defined by a MAC (media access control) address or an IP address. Also, data of the ingress port may be also used as the identifying conditions (or the identifying rules) of the processing rules (or the flow entries). Furthermore, the identifying conditions (or the identifying rules) of the processing rules (or the flow entries) may be set in the form of a representation in which some or all of the values of the header region of the packet to be treated as the flow are represented by using a normal representation, a wildcard character “*” or the like.
The contents of processing (or the action) of a processing rule (or a flow entry) indicates an operations such as “output to a particular port”, “discarding” and “rewriting of header”. For example, if the contents of processing (or the action) of a processing rule (or a flow entry) indicates identification information of an output port (an output port number and the like), the node device outputs the packet to the indicated port, and if not, the node device discards the packet. Instead, if the contents of processing (or the action) of the processing rule (or the flow entry) indicates the header information, the node device rewrites the header of the packet on the basis of the header information.
A node device in the OpenFlow network performs the contents of processing (or the action) of a processing rule (or a flow entry) on a group of packets (or a series of packets) that complies with the identifying conditions (or the identifying rules) of the processing rule (or the flow entry).
For example, when receiving a packet, an OpenFlow switch (OFS), which corresponds to a node device in the OpenFlow network, retrieves the processing rule (or the flow entry) associated with the identifying conditions (or the identifying rule) complying with the header information of the received packet from the route control information (of the flow table). If the processing rule (flow entry) complying with the receipt packet is found out as a result of the retrieval, the contents of processing (or the action) described in the action field of the processing rule (or the flow entry) is performed on the received packet. If no processing rule (or the flow entry) complying with the received packet is found as a result of the retrieval, on the other hand, the received packet is judged as the first packet. In this case, inquiry information of the received packet is transmitted to an OpenFlow controller (OFC), which corresponds to the controller in the OpenFlow network, via a control channel to request for determining the route of the packet based on the source and destination of the received packet; this is followed by receiving a processing rule (or a flow entry) for attaining the packet transfer along the determined route and then updating the route control information (or the flow table).
It should be noted that an initial state processing rule (or a default entry) is registered in the route control information (or the flow table), where the initial state processing rule describes identifying conditions (or identifying rules) of a low priority which are defined so as to comply with the header information of any packets. If no other processing rule (or flow entry) complying with the received packet is found, the received packet complies with the initial state processing rule (or the default entry). The contents of processing (or the action) of the initial state processing rule (or the default entry) is defined to instruct to transmit inquiry information of the received packet to the OpenFlow controller (OFC).
As mentioned above, the OpenFlow switch (OFS) determines processing to be done on a packet in accordance with the setting of processing rules (or flow entries) set by the OpenFlow controller (OFC). In particular, the “output” processing, in which a packet is outputted to a specified interface, is often used as the processing. It should be noted that the specified interface is not limited to a physical interface; the specified interface is not limited to the physical port and may be a virtual port.
As thus described, control of packets is attained by centralized control of OpenFlow switches (OFS) by an OpenFlow controller (OFC) in the OpenFlow network. One issue is that one OpenFlow controller (OFC) can control only a limited number of OpenFlow switches (OFS). Accordingly, an increase in the scale of the network, which causes an increase in the number of the OpenFlow switches (OFS), may result in that calculation of processing rules (flow entries) in the OpenFlow controller (OFC) and the like becomes a bottleneck of the network quality.
One approach to address this may be connecting a plurality of OpenFlow networks, each including one Openflow controller (OFC) and a plurality of OpenFlow switches (OFS) controlled by the OpenFlow controller, when the scale of the network is increased.